SGI designs graphics hardware to permit both direct and virtualized rendering. Direct rendering refers to the ability for normal programs to manipulate the graphics hardware directly. Users are hidden from the actual details of the hardware by either the OpenGL or IRIS GL graphics interfaces (implemented as shared libraries). Virtualized rendering refers to the ability to interleave rendering with other rendering processes and properly constrain rendering to any designated window.
Direct rendering is common on personal computers; on a PC, a program may directly manipulate the frame buffer. Direct rendering allows maximum graphics performance. Virtualized rendering is a must for window systems since rendering must be clipped to the window's drawable region. The X Window System is a good example of virtualized rendering. For common graphics architectures, direct access and virtualized access are traded against each other. Either a single application has direct access to the entire graphics subsystem for its own purposes, or a process, such as the X server, or perhaps the operating system kernel arbitrates access to the graphics resources.
SGI (along with other vendors of sophisticated graphics hardware) [19] provides both direct and virtualized rendering using hardware and operating system support. SGI graphics hardware does not expose a frame buffer for direct manipulation. Instead a bank of registers is mapped into the address space of a process wishing to utilize the graphics hardware. Graphics commands are generated by manipulating the banks of graphics registers. In conjunction with operating system support for virtual memory, the graphics hardware interface can be context switched between multiple processes, all apparently using the graphics hardware simultaneously.
Direct access to the graphics hardware is also virtualized. Rendering is window relative; arbitrary window clipping is performed by the hardware. A window's origin and clip can be updated by the window system without the knowledge or consent of a process rendering into the updated window.
The operating system resource which implements a virtual graphics pipeline is known in IRIX as a rendering node. Programs desiring to perform virtualized direct access allocate a rendering node and bind it to the window they are interested in rendering to. The rendering node may be rebound to other windows. Allocation and manipulation of rendering nodes is hidden by the graphics library implementation. Rendering nodes are a virtual abstraction of a particular graphics board's graphics context, so a rendering node is allocated for use with a single graphics board.
Like any virtualized resource, there is always the potential for thrashing. In SGI's architecture, there are a limited number of physical hardware contexts (sometimes only one); there are a limited number of clipping planes (necessary for arbitrary clipping); and there are a limited number of unshared display IDs (used for instantaneous buffer swaps when double buffering). The graphics systems are designed to handle average to heavy loads, but the potential for thrashing does exist. Even under extremely heavy loads, the operating system is designed to context switch the available graphics resources transparently.
The SGI X server plays a special role in virtualizing the hardware. The X server and the operating system kernel coordinate through a facility known as the Rendering Resource Manger (RRM). Only the X server has complete knowledge of every window's drawable region, origin, and display mode. Even without multi-rendering for PEX and OpenGL support, IRIS GL support requires that the X server must correctly maintain hardware clips and display IDs. The X server and the operating system kernel coordinate via special messages.
When the window layout changes, any window used for virtualized direct access rendering and whose drawable region was affected by the change must have the window's clip invalidated by the X server. A special RRM ioctl is used by the X server to communicate clip invalidations to the kernel. The kernel will mark any rendering nodes bound to the window with an invalid clip resource and unmap the virtual pages corresponding to the graphics hardware banks. The next time the process attempts to use the rendering node, the process will generate a page fault. The kernel will determine that the fault corresponds to the address of the unmapped graphics hardware. An RRM message will be sent to the X server to validate the clip of the window. The X server will receive the message, determine the correct clip for the window, and revalidate the window's clip and origin. The kernel will then remap the graphics hardware pages and resume the execution of the process. This entire sequence is transparent to the faulting graphics process. Figure 3 shows an example of how clip validation works.
Figure 3: RRM clip validation assisted by the X server.